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I.   INTRODUCTION 


A.   hlSIUHY  OF  THE  FORTRAN  LANGUAGE. 

FUHlHArj  was  produced  in  the  late  1  S  5  0  '  s  for  use  on  I  o  N'1 
computers.  With  the  backinq  of  IBM,  FORTRAN  became  w i  a  e 1 y 
accepted  and  was  subsequently  developed  for  many  machines 
during  the  I9601 s.  The  American  National  Standards 
Committee  specification  of  FORTRAN  in  l°o6  1 2. ]  has  araoualiv 
become  accepted  ana  most  oresent  compilers  conform  to  this 
stanaarc. 

In  1^76  the  committer  developed  a  draft  proposed 
American  National  Standard  FORTRAN  14]  as  a  reolacement  for 
the  original  Standarc.  The  FORTRAN  language  definition 
aescribed  in  the  prooosed  Standara  includeo  essentially  all 
features  of  the  original  Standara  with  the  major  exception 
being  the  removal  of  the  Hollerith  d  a  i"  a  type.  A  n u m d e r  of 
additional  capabilities  including  a  character  data  tyne  and 
file  oriented  input/output  were  also  added  to  the  lanauagp. 


FORTRAN  has  made  a  significant  contribution  to  computer 
technology.  Its  development  provided  a  language  that  was 
easily  learned  by  a  wiae  variety  of  people  ara  that  was 
available  for  use  en  existing  haraware.  oy  p  r  o  v  i  a  i  n  a  a 
packed  statement  form  which  aid  not  relv  on  the  presence  of 
blanKSf   f-ORTRAN   allowed  more  efficient  storage  of  proarams 


and  greater  ease  of  programming.  A'itn  t  n  e  use  of  the 
equivalence  statement,  the  control  of  storage  allocation  ov 
the  programmer  was  permitted  for  the  first  time,  f 9 ] 

6  i  n  c  e  its  oriainal  definition,  FORTRAN  has  become  the 
standard  scientific  computer  lanauage.  cecause  of  the 
portability  of  programs  written  in  FORTRAN  it  has  also 
become  a  common  intermediate  language  that  has  been 
generateo  ov  language  processors  and  compilers,  as  well  as 
one  of  the  standard  1 anauages  for  pro a  rem  portability. 

B.   THE  USE  OF  FOR f RAN  WITH  MICROCOMPUTER  SYSTEMS 

Kecent  advances  in  tne  construction  of  digital  circuits 
have  resulted  in  trie  availability  of  low-cost  L  S  i  computer 
components.  Ihese  components,  which  include  central 
processing  units,  memory  systems  and  peripherals  for 
input/output,  can  be  comDined  to  form  a  digital  computer 
known  as  a  microcomputer.  A  large  number  of  application 
areas  for  microcomputers  have  been  identified,  sucK  as 
intelligent  terminals,  dedicated  processors  ana  minicomputer 
control  tasks,  f 1 1 J 


In  contrast  to  the  advanced  technology  utilized  in 
microcomputer  hardware,  the  software  designed  to  support 
microcomputers  has  been  slow  in  developina.  A  great  deal  of 
applications  worx  has  been  done  directly  in  machine  language 
since  microcomputer  conf iaurat ions  have  often  lacked  the 
memory    and    input/output    capacity   to   support   program 


development  in  assembly  lanquage.  fhe  use  of  assembly 
language  has  Deen  supported  b  /  many  microcomputers  and  when 
combined  witn  a  text  editor  and  debugging  aids  formed  a 
useful  package  for  the  programmer.  To  date/  very  few  hign- 
level  languages  nave  been  developed  for  use  on  a 
microcomputer  system.  P L M  [  t>  1  is  currently  the  only  hiqn- 
level  microcomputer  systems  programming  languaoe  which  is 
widely  used . 

With  the  expanding  number  of  applications  for 
microcomputers^  high-level  languaaes  must  assume  an 
increasinclv  important  role  in  the  develooment  of  software 
for  use  on  microcomputer  svste^s.  An  implementation  of  the 
f-  0  R  f  k  A  ft  Ianauage  could  be  a  valuable  addition  to  the  '-'ion- 
level  languages  that  can  be  utilized  for  microcomputer 
software  suppc  rt . 

The  purpose  of  this  paper  is  to  describe  the  desicn  and 
implementation  of  an  L  A  L  R  (  1  )  FORTRAN  grammar  for  use  with  a 
self-hosted  compiler.  An  overall  system  design  to  support; 
the  rORTRAN  language  on  a  microcomputer  svstem  is  also 
oesc  r  i  oed. 

C.   MOTIVATION  FUR  Aw  |_AlR(1)  GRAMMAR 

One  of  the  major  techniques  used  in  current  compiler 
construction  is  cased  on  wor<  done  by  Knuth  18J f  wno 
developed  deterministic  parsing  algorithms  for  the  left-to- 
right  translation  of  languages  defined  by  LR(k)  grammars.   A 
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grammar  is  LR(k)  if  each  sentence  it  generates  can  be  parsed 
from  left  to  right  in  a  single  scan  with  at  most  k  looohead 
symtDO  1  s  . 

LR(kJ  grammars  have  several  advantages.  Fhey  arf> 
unamoiguous.  Construction  alaorithms  exist  for  this  cl-^ss 
of  grammar  that  can  bulla  parse  action  tables.  A  parser  can 
use  the  tables  produced  bv  the  analyzer  to  determine  if 
language  statements  defines  oy  the  a  r  a  m  m  a  r  are  well-formed. 

L  R  (  k  )  grammars  alwavs  reouire  a  lookaheaa  of  <  symbols 
for  the  parser  to  determine  the  next  state.  LALR(k) 
grammars  differ  from  !  R  (  <  )  in  that  the  loo<anead  is  only 
performed  when  necessary ,  thus  producing  much  smaller  oarse 
taoles.  Ihe  largest  class  of  currently  implementacle  I.k(k) 
grammars  are  LALR(l), 

An  efficient  Darser  can  oe  written  to  intercret  oarse 
action  tables  for  LALR(l)  grammars  (11.  The  parser  is  a 
table-ariven  pushdown  automaton  that  assumes  a  seauence  of 
states  (shift,  reduce,  accept/  or  error)  while  scannino  t he 
input.  Decisions  are  based  on  the  next  input  symbol  and 
information  accumulated  on  a  oarse  stack.  The  final  state 
inaicates  whether  the  input  was  well-formed. 

The  availability  of  such  an  L  A  |_  R  Parser  Generator   [lu] 

for  use  in  developing  a  FORTRAN  grammar  was  the  major  factor 

in  aetermininq  the  method  of  constructing  a  compiler  for  use 

in    the    implementation   of   the   FORTRAN  language   on   a 
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microcomputer  system.  The  LALR  Parser  program  accepts  a 
backus  naur  Form  (6I\F)  grammar  definition  as  input  ana  tne 
number  of  lookaheads  gl lowed/  and  determines  if  the  grammar 
is  amoiguous.  If  the  grammar  is  acceotaole  then  oarse 
tables  are  producea  that  can  be  usea  with  a  parser/  and 
syntactic  and  semantic  analyzer  routines/  to  provide  the 
basis  for  the  systematic  construction  of  a  compiler.  Tne 
parse  tables  that  are  produced  are  compatiole  with  tne  P  L  M 
programmina  1 anauage  but  can  be  modified  for  use  with  ot^er 
I  anguaqes . 

The  LALk  Parser  Generator  was  instrumental  in  ene 
development  of  trie  large  grammar  necessarv  for  F  u  P  I  ^  a  '  ■  since 
oNF  definitions  could  ce  testea  and  debugged  incrementally 
as  tne  grammar  was  developed. 
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II.   GRAMMAR  SPECIFICATION  AND  DESIGN 


A.  INTRODUCTION 

[his  chapter  describes  the  reauireinents»  goals*  and  the 
design  decisions  considered  during  the  development  of  the 
L  A  l  R  (  1  J  PORTRAIT  grammar.  in  addition/  suagested  extensions 
to  tne  grammar  are     included. 

[he  final  two  pass  version  of  the  L  A  L  R  (  U  F 0 P  I R  A  N 
y r a m m a r  is  contai^ec  in  Appendices  A  and  B .  The  syntax  of 
the  F  0  R  I  R  A  N  statements  that  this  crammar  oefines  is  included 
in  the  1 VV  7  o  draft  proDosed  American  National  Standard 
F  0  R  I  R  A  h  .  [he  few  deviations  from  the  proposed  Standard  are 
noted  in  the  "Statement  Restrictions"  section  in  this 
chapter . 

B.  GRAMMAR  SPECIFICATION 

The  syntax  of  individual  F  0  P  T  P  A  N  statements  and  their 
correct  ordering  within  program  units  described  in  tne 
proposed  Standard  were  used  to  form  the  basis  of  tne  grammar 
design.  it  should  oe  noted  that  the  grammar  developed  to 
define  the  proposed  Standard  also  syntactically  defines  tne 
19  56  AuSI  Stanaard  FORTRAN.  Not  considered  in  tne  design  of 
the  grammar  were  language  extensions  that  have  been  maoe  to 
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ANSI  Standard  F  0  k  T  R  A  i^  by  language   processors*   unless   they 
have  been  included  in  the  proposed  Standard. 

C.   GRAMMAR  DESIGN 

F  U  R  I  R  A  N  as  described  in  Rets.  2  ana  U  has  Deen 
considered  an  inherently  ampiguous  language.  In  oroer  to 
completely  define  the  syntax  of  the  language  an  arrbioucus 
grammar  is  required.  Since  L  A  L  R ( 1  )  grammars  must  be 
unambiguous  by  definition,  this  incompatibility  created 
problems  during  the  aevelooment  of  the  grammar. 

in  tne  oesion  of  tne  arammar  two  approaches  were  t  a  *  e  n 
in  oraer  to  solve  these  d  r  o  n  1  e  m  s  .  First/  consi aeration  was 
given  to  exoanaina  the  grammar  to  define  more  tnan  the 
syntax  allowed  when  compensating  actions  could  oe  performed 
in  the  semantics  ot  a  compiler  implementing  the  grammar. 
Second,  if  that  approach  failed  then  tne  grammar  was 
restricted  to  aefine  only  a  subset  of  the  syntax  of  tne 
1 anguage . 

1 .   Des  i  qn  Goals 


The  design  goals  for  the  LALR(l)  FORTRAN  grammar 
were:  (1)  to  adhere  as  closely  as  possible  to  the  proposed 
A  N  3  Standard  requirements  of  the  FORTRAN  lanquage 
definition,  (2)  to  maintain  overall  simplicity  in  tne 
grammar  ana  (3)  to  develon  a  orammar  small  enouon  to  re 


utilized  in   a   sel  f-hostea   compiler   for   a   m  i  c  roccrrpu'-  e  r 
system  with  1  6  K  bvtes  of  memory. 

I .    Tokens 

The  tokens  in  the  initial  grammar  desion  consisted 
of  special  characters*  reserved  words*  ar  identifier*  a 
statement  1  a  o  e  1  *  a  format  incut*  and  character*  integer* 
real  and  douole  crecision  constants.  As  the  aramrrar  was 
developed  it  was  necessary  to  create  statement  termination* 
array  identifier*  exponent iaf ion  ooerator  3  n  d  concatenation 
operator  tokens  in  nrcer  to  resolve  ambiguities. 

a  .   K  e  5  e  r  v  e  ri  -'■  o  r  j  s 

In  order  to  recognize  F 0 H T K A (M  <ey  words*  such  as 
DIMtNSION*  COMMON*  RtAu*  etc.*  t  h  e  use  of  reserved  woras  was 
required  in  the  lanquage  definition.  In  the  ANSI  and 
prooosed  A N S  Standard  FORTRAN  key  woros  were  not  reserved 
and  could  also  be  usee  as  identifiers.  however*  in  order  to 
conform  to  normal  grammar  techniques  reserved  word  tokens 
were  created  to  distinguish  them  from  identifiers.  In 
addition  to  the  FORTRAN  key  words  the  logical  constants 
•  TRUE,  and  .FALSE..*  the  relational  operators  .  E  Q  .  *  .  N  E  .  * 
.  G  E. .  *  .Gl.*  .LE.  and  .  L  T  .  *  and  the  logical  operators  .AND.* 
.  N  0  I  .  *  and  .OR.  were  included  as  reservea  words  for  ease  in 
later  implementation  of  the  grammar. 
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D.   Statement  FerTinat  ion 

[he  FORTRAN  lanauage  does  not  have  a  special 
"end-of-statement"  delimiter  equivalent  to  the  penoa  in 
COtiUL  or  the  semicolon  in  ALGUL.  Thus*  in  order  to 
terminate  each  statement  definition  in  the  grammar  an  "ena- 
of-statement"  token  «as  created.  Without  this  token,  the 
LALK  Parser  Generator  was  unable  to  differentiate  between 
individual  statements  in  the  lanauage.  The  use  of  this 
token  must  ce  i. mole men  ted  in  any  com oiler  t  h  at  utilizes  fne 
grammer  out  should  he  transparent  to  the  us«=r  or  t  n  e 
COmD  i  ler. 

c.  Statement  Labels 

The  soecial  to<en  "statement  label"  was  used  to 
define  the  statement  laoels  niven  to  specific  statements. 
However,  references  to  statement  labels  within  a  statement 
(.e.g.*  GO  TO  lu)  were  defined  as  integer  constants. 

d.  Soecial  Characters 

Durina  the  development  of  the  grammar  the 
initial  set  of  SDecial  characters  caused  ambiguities  in  the 
definition  of  an  expression.  The  differences  in  the  use  cf 
the  multiolication  operator  *  ana  the  exponentiation 
operator  **  could  not  be  resolved.  A  similar  problem  was 
encountered  with  the  ci vide  oDeratc  /  and  tne  concatenation 
operator  //.   it  became  necessary  to  create  additional 
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tokens  for  the  exponentiation  operator  and  the  concatenation 
one r a t  o  r . 

e.  Format  I nout 

The  "format  input"  token  was  include a  in  thf 
grammar  design  to  allow  format  statements  to  be  nandlea  in 
the  semantics  of  a  compiler  implementina  the  arammar,  rather 
than  in  the  grammar. 

f.  Head  Paren 

A  major  problem  was  encountered  in  aeveloping 
the  arammar  to  define  the  FORTRAN  read  statement.  The 
syntax  ot  the  unformatted  r^ad  statement  *as  Pt&u  t.  <co"trol 
information  1  i  s  t  >  )  ,  wM le  the  syntax  of  the  formatted  read 
statement  w  ^  s  ft  E  A  D  <format>.  rti  t  h  both  the  format  ana  the 
control  information  list  allowed  to  be  an  expression,  a 
description  of  the  syntax  of  the  two  reao  statements  o^came 
kEAL)  (  <expression>  )  and  READ  <expression>.  Since  the 
expression  syntax  included  a  rule  that  stated  <exrression> 
:  :  =  (  <expression>  )  there  was  no  way  for  an  LALR(l)  aramrrar 
to  unamb i quous 1 v  define  Doth  t/oes  of  read  statement.  To 
solve  this  problem  a  "read  paren"  token  was  created  to 
define  the  beginning  of  an  unformatted  read  statement. 
Although  it  is  syntactically  correct  to  parenthesize  the 
format  in  the  formatted  read,  in  utilizina  the  grammar  the 
design  imposes  the  recuirement  tnat  a  parenthesis  following 
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the   K  t  A  u   automatically   indicates   an    unformatted    read 
stat  emen  t . 

g .   Identifiers  and  Array  Identifiers 

Identifiers  were  initially  designed  to  be  any 
sequence  of  one  to  six  letters  or  numbers  D  e ginning  with  a 
letter*  which  was  not  a  reserved  wora.  however,  a  Drnolem 
was  encountered  in  differentiating  between  function 
references  and  array  element  references.  The  syntax  of  Doth 
as  defined  in  the  proposed  Standard  consists  of  ^n 
identifier  followed  by  a  parenthesized  list  of  expressions, 
for  example  A(o,  :»<:)  a  n  j  ^AX(6r3/2).  Thus,  in  oruer  to 
resolve  this  oroblem  an  array  identifier  token  was  createc. 

l)  i  s  t  i  ngu  i  s  h  i  no  between  identifiers  and  array 
identifiers  remains  a  nontrivial  problem  and  must  oe  handled 
in  the  semantics.  Oeoenoino  on  the  technique  used  it  may 
impose  the  reauirement  that  arrays  cannot  be  referenced 
prior  to  their  definition  in  a  dimension  statement. 

3 .   Expressions 

The  initial  grammar  design  included  the  F  U  R  T  R  A  N 
arithmetic/  character  and  looical  expressions  as  separate 
entities.  These  expressions  ar^  each  constructed  usina 
identical  operands  -  identifiers,  array  element  references 
and  function  references.  The  specific  tyoe  of  each  operand 
(character,  inteaer,  etc.)  must  be  examined  in  oraer  to 
determine  whether  it   is   valid   for   use   in   a   particular 
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expression.  The  use  of  these  identical  operands  again 
caused  the  grammar  to  be  ambiguous.  The  solution  was  to 
define  one  aeneral  expression  for  overall  use  in  the  FuRTPAN 
grammar.  The  rules  that  were  develooed  for  this  expression 
definition  enforce  operator  precedence  for  eacn  tycie.  The 
semantics  of  a  compiler  that  uses  such  a  grammar  must  be 
responsible  for  determining  what  SDecific  type  of  expression 
is  oeing  used*  and  whether  the  operands  are  valid  within 
that  type  of  exoressicn. 

Another  o  r  o  b  1  e  m  encountered  in  the  expression 
definition  was  in  enforcing  par^ntnesizec  expressions  as 
reuui  rea  in  some  F 0 K T R A i\i  statements.  fn°  syntax  of  an 
expression  i nc 1 udec  the  rule  <expression>  ::= 
(<expression>).  This  resulted  in  the  reduction  of  a 
pa ren t nes i zed  expression  to  an  expression  prior  to  its  use 
in  a  statement.  In  oroer  to  enforce  a  Darentnesized 
expression  the  rule  was  modified  as  follows: 

<expression>  ::=  <oaren  exoression> 

<paren  expression>  ::=  (  <expression>  ) 
The  second  rule  could  then  be  used  in  any   statements   where 
parenthesized  expressions  were  renuireo. 

4 .   Complex  Constants 

A  furtner  examole  that  illustrates  the  problems 
encountered  in  constructing  an  LALR(l)  grammar  is  the 
definition  required  for  a  Comdex  constant.   Syntactically  a 
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complex  constant  was  defined  as  (  <real  constant>  ,  <real 
constant>  ).  However,  this  definition  coula  not  be  useu  in 
the  grammar.  Examination  of  the  fol lowinq  grammar  rules  is 
necessary  in  order  to  understand  tne  oroblem: 

<complex  constant>  ::=  (  <real  constant>  ? 

< rea 1  cons  t  an t  >  ) 

<return  statement>  ::=  RETURN  <expression> 

<esxpression>  ::=  <constant> 

!  <caren  expression> 

<oaren  expression)  ::=  (  <•=»  xd  re  ss  i  on>  ) 

<constant>  ::=  <real  constanf> 

oased  on  f-nese  arammar  rules  the  reoinninc  of  one 
Derivation  for  the  return  statement  was  RETURN  (  <re-d' 
constant>.  Durino  tne  oarsino  of  this  statement  with  a  left 
parenthesis  and  real  constant  on  the  stack  tne  LA|_k  Parser 
could  not  determine  if  the  real  constant  should  be  reduced 
to  a  constant  for  eventual  use  in  the  return  statement,  or 
whether  to  stack  a  comma  for  eventual  use  in  a  complex 
const  an t . 

In  attempting  to  overcome  the  oroblem  several 
alternative  rules  were  examined  for  the  comolex  constant 
definition  that  produced  similar  ambiguous  results.  The 
final  unambiguous  definition  was  as  follows: 

<comolex  constant)  ::=  <complex  heaa>  <expression>  ) 

<complex  head>  ::=  (  <exoression>  , 
These  rules   reauire   the   semantics   to   determine   if   the 
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expressions  in  the  complex  constant  definition  are   in   fact 
real  constants. 

5.   Input/OutDut  Specification 


Ihe  syntax  of  the  FORTRAN  input/outout  statements 
included  a  large  number  of  input/outout  specifications 
associated  with  each  statement,  including  unit  numbers* 
error  specifiers  and  file  soecifiers.  The  ordering  of  these 
specifers  and  the  soecific  incut/output  specifications 
allowed  with  each  statement  were  initially  included  in  the 
grammar  design.  However,  aue  to  t  r\e  large  numoer  of  arammar 
rules  required  to  enforce  this  syntax  a  general  incut/cutout 
specification  replacec  them  in  the  final  grammar.  This 
requires  the  interpretation  of  specific  input/outout 
specifiers  for  the  input/output  statements  in  the  semantics. 

t>.   Statement  Restrictions 


The  grammar  for  the  individual  Fu^TPAN  statements 
was  originally  designee  to  s^ric^ly  enforce  fne  syntax  of 
the  statements  in  the  proposed  otanoard.  uurinq  the 
development  of  the  grammar  it  was  decided  in  several  cases 
to  define  only  a  subset  of  the  syntax  in  the  qrammar  in 
oraer  to  decrease  the  numoer  of  rules.  Both  the  common  and 
data  statement  syntax  enforced  by  the  grammar  allow  only  one 
namelist.  uotional  commas  for  the  go  to,  tyoe  and  go 
statements  were  also  excluded  from  the  arammar  develoneo. 
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The  implicit  statement  cosed  a  special  problem  which 
was  never  entirely  resolved.  The  length  specification  in 
the  character  implicit  statement  can  be  an  expression  and  is 
defined  oy  tne  fol lowina  syntax: 

<implicit  statement>  ::=  IMPLICIT  CrtAKACTtR 
*  <expression>  (  <letter  ranae  list>  ) 
The  combination  of  an   expression   and   a   left   parenthesis 
caused    ambiguities   in   the   grammar   that   coulu   not   be 
eliminated.   The   eventual   solution  *as       to   restrict   the 
syntax  for  the  character  lengtn  to  an  integer  constant. 

1.        Optional  Statement  Desinn 


if  reouireu  for  semantic  analysis*  many  of  tne 
grammar  rules  in  Aopenoices  A  and  8  that  define  the  FORTRAN 
statements  could  be  restructured  ana  the  overall  FORTRAN 
grammar  would  still  meet  the  requirements  of  an  L  m  L  r<  (  1  ) 
grammar.  These  alternate  statement  definitions  might  ce 
useful  in  semantic  code  generation. 

A  simple  example  of  this  is  illustrated  by  tne 
following  two  alternate  definitions  available  for  th*» 
dimension  statement: 

<dimension  stmt>  ::=  DIMENSION  <array  declaration> 

!  <dimension  stmt*  r 

<array  declaration> 
<aimension  stmt>  ::  =  <dimen  heaa>  <array  declaration> 
<dimen  head>  ::=  DIMENSION 

!  <dimen  head>  <array    aeclarat ion>  , 
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The  first  definition  was  chosen  for  use  in  the  final 
grammar  because  it  required  fewer  rules.  The  second  set  of 
rules  may  be  desired  for  a  compiler  utilizing  the  grammar  in 
order  to  determine  when  the  last  array  declaration  is  beinq 
processed . 

6 .   Splitting  the  G  r  a  ^  m  a  r 

The  original  LALR(l)  arammar  was  desianeo  to  apf ine 
the  syntax  of  all  the  statements  in  the  FORTRAN  language. 
The  initial  grammar  definition  that  was  developed  contained 
approximately  3  5  o  rules.  The  tao'es  aeneratea  by  the  L  A  l_  R 
Parser  for  this  grammar  took  o  v  p  r  11K  bytes  or  memory. 
These  tables  were  much  too  large  to  be  implemented  in  a 
selt-hostea  comciler  for  a  1  to  K  microcom cuter  system  wi  fh  g 
4K  operating  s/stem.  Consequent  1 y  the  arammar  was  split 
into  two  sections.  The  first  section  containeo  the  rules 
for  the  data  and  environment  definition  statements  including 
program*  subroutine*  function*  block  u  a  t  a  *  format*  entry, 
aata*  specification  and  statement  function  statements.  Tr>e 
second  section  contained  the  rules  aef inino  the  format* 
entry*  data  and  executable  statements. 

Splitting  the  grammar  in  this  manner  had  two 
advantages.  The  larce  table  size  was  reduced  to  3  ft  0  0  bytes 
for  section  one  and  4200  bytes  for  section  two.  The  split 
grammar  made  it  necessary  to  sclit  the  compiler  into 
separate  programs  tor  each  section;  thus  different  semantic 
actions   associated   with   identical   grammar  rules  could  oe 
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varied  within  the  seoarate  programs.  For  example/  a 
reference  to  an  array  element  coulo  be  handled  in  a 
different  manner  in  each  of  the  oroarams. 

A  significant  disadvantage  of  splitting  the  grammar 
was  the  difficulty  imposed  in  the  desian  of  a  compiler  that 
utilizes  the  grammar  to  process  more  than  one  proaram  unit. 

The  two  grammars  were  designed  so  that  they  could 
easily  Oe  combined  for  use  in  a  compiler  that  ocerated  in  an 
environment  where  memory  size  was  not  as  restricted. 

D.   GRAMMAR  AUGMENT  A  i  ION 
1.   Overview 


I  h  e  initial  grammar  design  included  rules  defining 
the  re  1  a t i ons n i ps  among  urogram  units*  enforcino  statement 
order  and  defining  the  statements  allowed  within  the  program 
units.  These  rules  were  subsequently  oroDpeo  primarily  to 
reduce  the  size  of  the  parse  tables.  In  an  environment 
where  the  size  of  the  compiler  is  not  critical  thesp  rules 
would  provide  a  useful  extension  to  the  grammar. 

£  .   Proqr am  Units 


The  proaram  units  defined  oy  the  FORTRAN  lanquage 
are  the  main  orogram,  and  the  function*  subroutine  and  block 
data  subproarams.  A  FOR  TRAM  program  must  have  no  more  than 
one   main   program   and   can   have   any  number  of  additional 
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subprograms.   Further,  these  program  units   can   be   in   any 
order.     Ihe   LA|_R(1)   qrammar   rules  that  were  developed  to 
enforce  these  relationships  are  as  follows: 
<orogram>  ::=  <proqram  unit> 
!  <subprogram> 

!  <suborogram>  <crogram  unit> 
<proaram  unit>  ::=  <main  proqram> 

!  <program  unit*  <suoorogram  unit> 
<sudd  rograTi>  ::=  <subprooram  unit> 

!  <subproorain>  <subprogram  u n i  t > 
<suproaram  urn  t>  ::=  <  f unction  suDproqram> 

I  <suhrouf  me  subprogram^ 
!  <block  oata  subprogram> 
These  Droduct ions  could  oe  of  value  if  more  than  one  program 
unit  is  to  oe  compilec  at  the  same  time. 

3 .   Statement  Urgerinn 

Several  versions  of  an  L  a  L  3  (1  J  grammar  were 
Developed  to  enforce  statement  ordering  within  program  units 
ana  the  types  of  statements  permitted  in  each  orogram  unit. 
An  LALK(l)  grammar  that  met  these  requirements  is  oresen  ted 
in  Appendix  C.  The  parse  tables  generated  for  the  nrammar 
in  ApDendix  C  took  approximately  220  0  bytes  of  memory. 

These  rules  could  dp  included  in  a  compiler  that 
implements  the  qrammar  if  the  memory  space  reouired  is 
availaole.   An  alternative  would  be  to  substitute  the 
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appropriate  semantic  actions  as  is  described  in   the   aesign 
of  the  compiler  presented  later  in  this  pacer. 
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III.   SYSTL^  DESIGN 


A.   OVtKVlEW 

The  system  desian  recommended  for  implementation  ot  tne 
FOR ! RAN  languaoe  on  a  microcomputer  consists  of  three 
subsystems:  a  FORTH  Aim  compiler  that  generates  a  relocatable 
intermediate  I snouage  macule  for  eacn  pronram  unit  fmain 
program*  subroutines/  functions/  or  block  a  a  t  a  J  in  tne 
F  0  k  I  N  A  I'  j  source  file*  a  loader  that  linKs  the  moaules  that 
nave  been  generatea  o  v  tne  compiler/  and  ^n  interpreter  thot 
executes  the  inferrr,  eaiate  lancuage. 

The  system  that  is  described  is  aesigned  to  execute  on 
the  Intel  8  08  0  microcomputer  with  1  b K  bytes  of  memorv  under 
the  CP/M  131  operatinc  system.  C P / M  is  a  monitor  control 
proaram  that  provides  a  number  of  basic  lnput/outout 
functions/  a  console  command  processor?  ana  a  comprehensive 
file  management  packaae  for  use  with  a  file  system.  Tne 
file  system  is  maintained  on  diskettes  (floppy  disks)  which 
contain  c?56K  bytes  of  storage.  This  operatinc  system  also 
supports  a  text  editor/  a  dynamic  debuager  ana  the  Tntel 
806  0  assembler.  C P / M  takes  4  K  oytes  of  memory;  therefore 
the  system  desian  ciscussed  for  tne  implementation  of 
FORTRAN  has  1 2 K  bytes  of  memory  available.  Tne  use  of  C P / M 
or  an  eauivalent  system  on  the  8  0  8  0   microcomputer   airectly 
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affected  the  desian  requirements   ana   recommendations   made 
for  the  implementation  of  FORTRAN. 

B.   COMPILER 

1  .   Organization 

Splitting  the  grammar  into  two  sections/  as  noted 
previously/  had  a  direct  impact  on  the  compiler  assign.  Tne 
compiler  was   originally   envisioned   as   one   program   with 


provisions   for   multiple  passes.   Tne  implementation  c 
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solit  FORI  KAN  grammar  required  a  separate  program  for  each 
grammar  and  a  control  orogran  that  provided  linxage  between 
the  two  programs. 

To  execute  tne  compiler  the  user  of  the  system  would 
invo<e  the  control  proqram/  and  pass  the  name  of  the  source 
file  to  oe  compiled  in  the  command  line  as  a  parameter  to 
the  program.  The  control  proaram  would  '■hen  manage  the 
interfaces  necessary  between  tne  pass  1  ana  pass  2  compiler 
proarams  required  in  the  compilation  process.  The  final 
output  would  be  a  file  containing  the  intermediate  lanquaae 
generated  bv  the  compiler. 

The  system  is  designed  so  that  the  control  program 
resides  in  memory  ourino  the  entire  compilation.  Ihe  symbol 
table  area  is  left  in  memory  for  use  Dy  the  oass  2.  program 
after  the  pass  1  procram  nas  completed  execution.  The  pass 
2.    program  overlays  tne  pass  1  proaram  when  read  into   memory 
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dv  the  control  program.   The  memory   configuration   tor   the 
implementation  of  this  design  is  presented  in  rigure  1 . 
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This  section  ciscusses  the  functions/  the  aesign 
requirements  ana  recommendations  for  the  control  program, 
the  pass  1  and  pass  d  proarams/  and  the  interfaces  reuuired 
among  them  necessary  to  imDlement  the  F U R 1  A i\j  compiler  based 
on  the  L  A  L  R  (  1)  FORTRAN  a  r  a  m  m  a  r  . 

i. .   Control  Program 

The  main  ourcose  of  the  control  orogram  is  to 
control  the  overall  compilation  process.  In  orrjer  to 
accomplish  this  it  must  perform  two  Dasic  functions:  f  1  )  the 
loading  of  the  Dass  1  ana  pass  3  programs  and  the 
initialization  of  their  execution/  and  ( d.)  the  maintenance 
of  comrron  information  such  as  compiler  togoles  ana  symbol 
taole  necessary  to  both  oasses.  This  reauires  t  n  a  t  tne 
control  proaram  remain  in  memory  auriny  the  ent  ir=> 
C  omp  i  1  at  i  on  . 

The  Dul k  of  the  executable  code  for  the  control 
proaram  resides  in  memory  just  below  the  C  P / M  opera  tin a 
system  (see  Figure  1  J  .  Uoon  initiation  of  the  program  by 
the  user/  execution  beoins  at  100  hex  (100HJ  and  d^ 
immediate  jump  is  performed  to  the  first  executable  byte  of 
coae  located  in  the  upper  part  of  memory. 

The  first  task  the  control  program  must   perform   is 

to  decide  whether  it  is  being  invokea  from  either  the  pass  1 

or  pass  2.    program   or   at   thp   initiation  of   the   FORTRAN 

compiler.    The   appropriate   actions   can  then  be  provided 
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based  on  this  decision.  A  control  *  I  a  g  which  can  be  altered 
by  the  pass  1  ana  pass  2  programs  can  be  useo  to  implement 
this  reauirement. 

rthen  the  control  prooram  is  executea  for  tne 
initialization  of  a  compilation  it  should  perform  the 
following  functions:  (1)  initialize  its  "scratcn  pao"  area 
for  use  by  the  oass  1  and  pass  2  orograms,  (<f)  save  the 
file  control  block  for  the  FORTRAN  source  file  and  open  tne 
file  for  i  n  p  u  t  /  (3)  maintain  the  tile  control  bloc'<  for  tne 
intermediate  languaoe  file  anrj  open  it  for  outcut/  ( 4 ) 
initialize  the  symbol  table  area»  (5)  r  e  a  a  the  executable 
iCu^J  tile  for  the  oass  1  croaram  into  memory  beai  nni  na  at 
100H,  ana  (o)  jump  to  l^uH  to  transfer  control  to  the  pass 
1  program . 

•(hen  the  control  prooram  is  invo<ea  at  tne 
completion  of  the  pass  !  orogram  it  should  check  for  a  fatal 
error  in  the  oass  1  phase  of  compilation  which  would 
terminate  execution.  If  none  is  found*  the  CO M  file  for  tne 
pass  d  program  can  be  read  into  memory  anc  control 
transferee)  to  100H  to  begin  execution  of  tne  oass  d    prooram. 

when  the  control  orogram  is  executed  via  a  transfer 
from  the  oass  d  program  it  should  again  checx  for  a  fatal 
error  in  the  oass  ?  phase  of  compilation  ana  terminate 
execution  if  necessary.  It  must  also  aetenr  ine  if  another 
program  unit  is  to  be  comoiled.  If  an  aJditional  orogram 
unit  is  to  be  comcilea  the  control  orogram  must  reinitialize 
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the  symbol  table  and  "scratch  pad"  area*  with  the  exception 
of  compiler  toggles/  and  reloaa  ana  transfer  control  back  to 
the  pass  1  orogram  to  continue  the  compilation  process.  if 
no  more  program  units  are  present  on  the  source  file»  the 
control  program  must  close  the  FORTRAN  source  file  ana  trie 
intermediate  language  file  and  return  control  to  the  L  P  /  M 
operating  system. 

M aintenance  of  the  file  control  blocks  by  the 
control  program  for  both  the  FORTRAN  source  file  am 
intermediate  language  file  is  critical  to  the  system. 
Pointers  must  oe  maintained  for  both  files  in  order  to 
determine  the  correct  record  to  oe  orocessen   tor   input   or 

OU  t  DU  t  . 

Fhe  "scratch  n  a  a  "  area  located  in  the  control 
program  is  available  for  use  by  both  the  pass  1  ana  pass  ? 
programs.  Information  maintained  in  this  area  can  incluae 
compiler  toggles*  error  flags*  and  any  other  interface 
information  reguired  by  the  pass  1  and  Dass  d    programs. 

3 .   Pass  1  Program 

The  pass  1  program  implements  the  grammar  presented 
in  Appendix  A.  This  proaram  Drocesses  the  FuRTPAN 
statements  up  to  Cout  not  including)  the  first  executable 
statement.  Routines  for  syntactic  ana  semantic  analysis* 
symbol  table  manipulation/  and  a  oarser  must  be  included  in 
the  orogram.   This  section  discusses  the  design  requi  regents 
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imposed  by  the  FORTRAN  q  r  a  m  m  a  r  and  some  additional  design 
considerations  necessary  for  implementation  of  the  program. 
The  parser  and  scanner  descrioea  in  this  section  were 
implemented  and  tested. 

a .   Parser 

[he  parser  that  was  adooteo  for  use  with  the 
pass  1  program  is  based  on  the  oarse  action  generation 
algorithms  used  to  analyze  L.  A  L  h  (  1  )  grammars. 

The  parser  controls  the  execution  of  the  pass  1 
proaram.  Jt  receives  a  series  of  tokens  f  r  o  "■■  the  scanner 
ana  and!  y?es  them  to  ce^ermine  if  they  form  a  valid  s^ntenc*3 
in  the  FURTKAij  grammar.  It  bases  this  decision  on  the  next 
input  to<en  ana  information  previouslv  accumulated  on  a 
parse  stack  where  the  parser  states  are  maintained. 

The  basic  actions  o  e  r formed  ov  the  parser 
include  a  shift  action  tnat  reads  a  new  token  ana  pushes  the 
previous  state  onto  the  staCKr  a  reduce  state  that  poos  the 
number  of  elements  equal  to  the  handle  of  the  production  and 
outs  a  new  state  on  the  stack,  an  accept  state  that 
indicates  the  input  conforms  to  the  grammar,  ana  an  error 
state  that  inaicates  wnen  a  syntax  error  has  occurea. 
Additional  stacxs  can  be  used  in  parallel  with  t-he  oarse 
stack  that  relate  to  the  translation  of  the  proaram,  such  as 
pointers  into  the  symbol  table  ana  temoorary  values  usea  in 
reduc  tions. 
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In  order  to  stop  the  execution  of  the  pass  1 
program  the  grammar  allows  the  parser  to  proceea  unci)  it 
has  analyzed  an  ena  statement/  when  no  executable  statements 
are  found  in  the  program  unit*  until  it  has  analyzed  the 
reservea  word  in  the  first  executable  statement/  sucn  as  DO 
or  KEAD/  or  until  an  assignment  statement  is  recognizee.  in 
the  case  of  the  assignment  statement/  where  no  reservea  word 
is  contained  in  the  statement  (  »  .  g  .  /  A  =  3 ) »  it  parses  up  to 
the  eaual  sign.  The  information  previously  scanned  for  the 
executable  statement  must  be  saveo  for  use  by  the  pass  ? 
proaram  to  o  r  o  v  i  a  °  initialization  of  the  scanner  and  to 
allow  for  any  semantic  actions  that  need  to  be  performed, 
py  maintainina  a  stac*  that  always  contains  the  last  three 
tokens  orocesseo z  this  information  c^n  then  be  provided  to 
the  pass  d  program  via  tne  "scratch  pad"  in  the  control 
program . 

b .   Scanner 

Ihe  function  of  the  scanner  is  to  provide  trie 
tokens  defineo  in  the  FORTRAN  grammar  to  the  parser.  Tnese 
tokens  include  reserved  words/  special  characters/  tne 
exponentiation  and  concatenation  operators/  statement 
labels/  identifiers/  array  identifiers/  "format  inputs"/ 
"end-o f -s t at emen t s M /  and  integer/  real/  character/  and 
double  precision  constants.  The  scanner  that  was 
implemented  in  the  pass  1  program  encountered  no  special 
problems  in  recognizing  these  toKens  with  the   exception   of 
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identifiers^  array  identifiers   and   the   "end-of-statement" 
token. 

identifiers  and  array  identifiers  n  o  t  h  have  the 
same  structure.  They  are  a  sequence  of  one  to  six  letters 
or  digits  that  begin  with  a  letter.  In  oruer  to 
differentiate  between  t  h  e  m  ,  it  was  necessary  to  include 
interaction  with  the  semantics  necessary  for  processing 
dimension  statements.  when  the  reserve a  word  DIMfcNSIUN  was 
encounterea  d  f  1  a  a  was  set  to  indicate  tnat  a  token  o  *  this 
form  followed  Dy  a  left  parent nesis  was  an  arrav  identifier. 
This  flag  was  checked  bv  the  scanner  folio 'wind  the  initial 
test  for  reserves  words.  If  the  flag  was  not  set »  fr>e 
svnool  was  looked  up  in  the  symbol  table  to  determine  if  it 
was  an  arrav  identifier  defined  in  a  previous  dimension 
statement.  If  these  tests  failed/  the  token  was  assumed  to 
be  an  identifer.  The  use  of  this  tecnniaue  imposed  the 
requirement  tnat  arrays  could  not  be  referenced  in  any 
FORIRAN  statement  prior  to  their  declaration  in  a  dimension 
stat  ement  . 

The  recognition  of  the  end  of  a  F  U  P  f  ft  A  ft 
statement   by  the  LALR(l)  grammar  implementation  reouireo  an 

"end-of-statement"   token   transparent   to  the    user.     A 

lookahead   feature  was  used  in  the  scanner  to  help  determine 

whether  the  next  line  was  a   continuation  of   the   previous 

statement.    Since   normal   F  0  R  T  R  A  ft   card  conventions   were 

maintained*  the  decision  could  be  baseo  on  a   line   position 


35 


pointer  that  maintained  the  "card  column"  position  of  the 
current  s  y  m  o  o  1  being  considered  by  the  scanner.  to  h  e  n  a 
carriage  return  and  linefeed  were  encountered  ,  the  position 
of  the  next  n  o  n  D  1  a  n  k  character  was  determined.  If  the 
position  was  not  "card  column"  six,  an  "end-of-stateme^t" 
token  was  passed  to  the  parser.  The  line  position  c  o  i  n  t  e  *" 
was  also  used  to  recognize  the  end  of  valid  statement  in nut 
at  "card  column"  seventy-Uo. 

c.   b  e  m  a  n  t  i  c  Analysis 

As  noted  previously/  the  gram mar  for  the  ca^s  1 
proaram  does  no^  enforce  the  oroer  and  tKe  types  o  + 
statements  allowed  in  eacn  program  unit.  Order  can  re 
enforced  in  the  semantics  of  t he  orcgram  by  the  use  of  two 
flags:  one  flag  to  determine  the  tyoe  of  program  unit  beina 
processed  (main  program,  subroutine/  function,  cr  block 
data),  and  a  second  flan  to  determine  if  a  particular 
statement  is  valid  cased  on  the  previous  statements  that 
have  been  processed.  Each  statement  in  the  grammar  for  this 
program  has  an  associated  reserved  woru.  Whenever  a 
reserved  word  for  the  statement  currently  being  processed  is 
encountered,  the  flags  can  be  checked  to  determine  if  the 
statement  order  is  correct  and  if  thaf  tyoe  of  statement  is 
valid  in  the  Drogram  unit. 

The  use  of  the  "format  incut"  token  in  the 
grammar  reauires  the  processing  of  format  statements  in  toe 
semantics  of  the  program.    In   addition,   this   information 
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must  be  saved  for  later  use  by  the  oass  2  program  in  the 
processing  of  the  executable  statements.  This  can  oe 
accomplished  by  either  writina  the  information  required  to  a 
floppy  disk  file/  or  by  saving  tne  information  in  the 
"scratch  pad"  area  of  the  control  program.  bince  the  number 
of  format  statements  may  be  large/  the  exact  implementation 
must  be  based  on  the  actual  memory  available  for  use  in  tne 
control  prooram. 

fhe  general  expression  definition  in  the  FORTRAN 
grammar  has  a  direct  impact  on  the  pass  I  program.  Tne 
semantics  must  enforc°  the  type  of  expression  (character/ 
logical/  or  aritnmertic)  allowed  within  each  statement  of 
the  FOKTKAM  input.  In  some  cases/  such  as  dimension 
statements/  only  integer  constant  expressions  are  valid. 
Integer  constant  exDressions  are  a  soecial  case  of  the 
arithmetic  expression  in  w  h  1  c  n  only  integer  constants  or 
variables  of  tyoe  integer  are  allowed.  The  semantics  of  tne 
compiler  must  also  process  these  special  expressions  and 
provide  for  their  evaluation  and  use. 

d.   Code  Generation 

The  type  of  code  oeneration  produced  by  a 
compiler  is  highly  dependent  on  the  system  in  which  it  is 
implemented.  The  design  decision  to  produce  an  intermediate 
lanauage  instead  of  executable  machine  code  was  based  on  t» o 
major  considerations.  First/  the  production  of  an 
intermediate   language   enhances   the  t r ansoo r t ao i 1 i t y  of  ao 
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eventual  system  implementation  of  FORTRAN  to  other 
microcomputers  that  suDport  PL/M.  Second,  the  existence  of 
an  interpreter  of  R  a  s  i  c  -  E  [  S  J  ,  which  translates  an 
intermediate  language  output  from  the  Basic-E  compiler,  has 
already  been  successfully  implemented  in  the  comouter 
laboratory  at  the  Naval  Postgraduate  School.  This 
interpreter  is  an  excellent  candidate  for  modification  for 
use  with  FORTRAN  if  the  intermediate  language  produced  ny 
the  FUKlKAN  comDiler  is  compatible  with  the  Basic-E 
intermediate  language. 

4.   Pass  2  P  r  o  q  r  a  m 


The  Dass  ?  crogra^  imolements  the  grammar  presented 
in  Appendix  p.  Tnis  proaram  processes  FORTRAN  executable 
statements.  Syntactic  and  semantic  analysis,  symbol  table 
manipulation,  and  oarser  routines  must  again  ce  included  in 
the  program.  This  section  describes  the  oesian  requirements 
imposed  by  the  FORTRAN  grammar  and  additional  uesign 
considerations  necessary  for  implementation  of  the  program. 

a .   Parser 

The  parser,  which  controls  the  execution  of  the 
pass  2.  program,  can  be  identical  to  the  oarser  descrioed  in 
the  previous  section. 

Execution  of  the  oarser  is  terminated  after  the 
end  statement  is  parsed.  At  this  point  the  program  must 
determine  if   there   are   additional   prooram   units   to   oe 
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c  o  m  c  i  1  e  a  .  Tnis  can  d  e  d  o  ^  e  cy  checking  to  see  if  a  n  y  t  n  i  n  a 
otner  than  a  soft  end-of-file  (i-^n)  or  a  h  3  r  o  e'^-of-f  i  le 
occurs  after*  t  ne  c  a  r  r  i  a  a  e  return  and  1  1  ^e'eec  following  the 
ena  statement.  T  K  e  aocrooriate  f  1  a  c  should  tr,er  n  e  ^et  in 
tKe  "sc."3tch  Dec"  area  c  *  the  control  crccrp-  a  ~  u.  execution 
t  ra^s^eTec!  to  the  ccpt  ro'  program. 

c .   Scanner 

F  h  e  scanner  designed   for  use   in   the   cass  2 

crogra-   cap   be   /  e  r  v   3  '  ~  '  '  e  r  to  *  ~  e  s:a"ner  in  t  -  e  p  a  -s  s 

p  r  o  a  r  a  -  .   He  "reaa  care^"   token   is  t  n  e   on  -   a  da  i  t  i  on  a  1 

token   ■ ■ ac   -  ^  s  t   be   rec  :""' z° j   by  the   -ass   _  ------ 

implementation, 

7  -*  e   differentiation   between   identifiers    ^  ~  ~ 

arra/  identifiers  is  no  longer  r?:0>  -e:  '  ~  t  *  e  se*a"t ■  : 
analysis.  ft t  this  c  o  i  n  t  all  arr-ava  -  a  *  ^  r  a  e  n  ceciarec  =  ~  ~ 
the  array  identifiers  are  corta,r*eo  in  the  s  v  -  r  c  i  t a fc  e  a^o 
can  ce  easily  reccg^i  ?e". 

ft  t  the  initialization  of  the  sca°"er»  the  t  o  k  e  n  s 

oreviously  taraei  in  the  cass  1  p - o  g  r 3  ~  for  t  n  e  first 
execut aoi  e  statement  ~ust  ce  recovered  from  the  "  s  c  r  ^  * :  " 
cad".  Code  *  o  r  providing  these  tokens  'r  o^ai/S"?  and  use 
oy  the  scanner  must  ce  included  %  ^  *  ~  e  crccra"  d  r  i  o  r  to 
obtaining  any  new  tokens  for  the  first  ex^.:  ,:ac'e  statement. 
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c.  Semantic  Analysis 

As  noted  previously*  the  format  specification  in 
the  format  statement  must  oe  handled  in  the  semantics  of  the 
proqram.  In  addition,  provision  must  be  made  for  retrieving 
the  information  that  was  produced  for  any  format  statements 
that  were  processed  oy  the  pass  1  proqram. 

The  orammar  for  pass  <?  imposes  additional 
requirements  for  expression  evaluation  not  necessary  in  the 
pass  1  progr-jm.  For  »  x  a  m  n  1  e  *  one  torn  of  the  print 
statement  wnich  is  acceptable  to  the  a  r  a  m  m  a  r  is  P  K I  f  i  T 
<expression>.  7  n  »  expression  may  either  be  an  i  n  t  e  q  e  r 
constant  designating  a  statement  1  a  h  e  1  /  or  a  character 
expression.  Thus*  the  semantics  must  allow  the  statement 
laoel  to  be  valid  as  it  is  parsed  up  throuoh  the  expression 
definition  associated  with  a  print  statement.  Similar 
requirements  exist  for-  the  read  statement  ana  complex 
constant  definitions. 

d.  Code  Generation 

Since  the  pass  2  program  performs  code 
generation  for  all  FORTRAN  executable  statements*  the 
proqram  may  exceed  the  memory  si?e  available.  If  this 
occurs*  consideration  should  be  given  to  either  restrict i no 
the  types  of  statements  allowed  for  use  in  the  F  o  R  I  P  A  W 
implementation  or  to  producing  parse  actions  in  pass  ?  and 
adding  a  pass  i  proqram  to  orocess  tnese  parse  actions.   Tne 
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additional  orogram  cculd  then  generate  the  intermediate 
language  cased  on  the  parse  actions/  associated  information 
and  available  symbol  table  information. 

C  .   L  U  A  D  £  R 

The  Dasic  task  of  the  loader  program  is  to  process  trie 
intermediate  lanouage  modules  oenerateo  by  the  compiler  for 
the  various  prooram  units*  and  to  produce  a  zero- a caress 
intermediate  lanouage  module  that  can  oe  executed  cv  the 
interpreter. 

The  following  tvD°s  o  *  information  associated  « i  t  h  eac^ 
intermediate  language  module  are  necessary  for  loader 
implementation:  (1)  t  h  e  name  of  the  current  module*  (.  2 )  a 
list  of  external  names  ana  references  with  definitions  of 
their  use/  (3)  the  aooress  of  the  first  byte  in  the  cooe 
area  of  the  current  module/  ana  U-i )  the  length  of  the  coae 
area  of  the  module  in  Dvtes.  Outout  from  the  loader  should 
be  designed  to  enable  further  linkage  if  all  external 
references  have  not  yet  ceen  resolved. 

The  actual  implementation  of  a  loader  was  not  considered 
part  of  t  n  i  s  thesis  Droject  ana  is  left  for  future 
cons  i  der at  ion. 
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D.   iNTtRRRETER 

The  function  of  the  interpreter  is  to  execute  the  zero- 
adaress  intermediate  language  oroouced  by  either  the 
compiler  or  the  loauer.  At  this  noint  all  external 
references  must  be  resolved  in  order  for  the  intermediate 
language  module  to  be  interoreted. 

.  Ihe  design  of  an  interpreter  j  3  dependent  en  the 
specific  machine  on  which  the  FORTRAN  languaae  is  to  Oe 
implemented.  The  run -time  ^o^i tor  used  for  executing  f  n  e 
intermediate  lanouaoe  oroduced  by  the  casic-h  compiler  [SI 
is  an  example  of  an  interpreter  that  has  been  successfully 
implemented  on  tne  b  0  d  0  unoer  tne  LP /  M  operating  system. 
The  monitor  provides  a  numoer  of  features  that  would  De 
useful  in  the  interpretation  of  FORTRAN  such  as  the  use  of  a 
floating  ooint  Dackage  (71  to  perform  arithmetic/  function 
evaluation  and  conversion  operations  on  "bd.  bit  floating 
point  numbers.  if  the  intermediate  language  generated  by 
the  FORTRAN  compiler  is  designed  to  be  compatiole  with  the 
language  produced  bv  the  Basic-E  compiler/  tne  modification 
of  this  interpreter  to  acceot  FORTRAN  would  areatlv 
facilitate  the  implementation  o*  FORTRAN  on  the  bOdO. 
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IV.   CONCLUSIONS 


The  successful  completion  of  the  formal  PORTKAu  qrammar 
demonstrates  the  feasibility  of  defining  an  ambiouous 
language^  such  as  FORTRAN,  using  an  L  £  L  R  i.  1  )  grammar. 
Ambiguities  in  the  grammar  can  De  resolved  by  providing  a 
broader  definition  for  the  language  and  compensating 
semantic  actions  by  a  comciler  that  implements  the  qrammar. 

The  FORT RAN  grammar  whicn  *as  aevelopeu  was  structured 
to  define  the  largest  possible  svntax  of  the  lQ/n  irdff 
proposed  American  National  Standard  FORTRAN.  however,  tMS 
should  not  nrevent  a  user  of  this  grammar  Iron  redefining  it 
to  meet  the  requirements  for  imolementation  on  a  particular 
machine. 

The  use   of   a   formal   1 anauage  ana       automatic   parser 

generation    methods    proved    extremely   valuable   in  tne 

construction  of  the  PGRTRAim  comoiler.   The  oarser   that  was 

available   for   use   in   orocessing   the   parse  tables,  when 

combined  with  syntactic  and  semantic  analyzer  routines,  led 

to   a   modular   design   and  the  systematic  construction  of  a 
comoiler  rather  than  an  ad  hoc  technique. 

The  system  design  which  was  oresented  to  support  tne 
FORIRAN  lanquage  on  a  microcomputer  system  with  16rs  bytes  of 
memory  is  feasible.    however,   the   lac<   of   mem or/   space 
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remains  a  problem.  it  is  recommend ea  that  consideration  De 
given  to  the  replacement  of  those  rules*  especially 
input/outout  statements*  which  coulo  be  tailored  to  tne 
specific  machine  on  which  the  comciler  is  implemented. 

It  is  hoped  that  the  L A L R ( 1 )  FORTRAN  grammar  ana  tne 
accompanyina  system  oesian  recommendations  will  establish  a 
basis  for  the  implementation  of  FOKTRAij  on  a  microcomourer 
system. 
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APPENDIX  A  -  FOR  TRAM  GRAMMAR  StCflUN  OnF 


<Drogram>  ::=  <orog  stmt >  <program  body>  <end  state> 

<prog  Stmt>  <end  state> 

<r>rogram  body>  <end  state> 

<end  s  t  a  t e> 

<subr  stmt>  <orogram  b  o  d  y  >  <ena  state> 

<subr  s t m t >  <end  state> 

<f unc  s  t  m  t  >  <orogram  body>  <ena  s  t  a  ^  e  > 

<*unc  s t m t >  <ena  s  t  a  t  e  > 

<b)ock  cat'a  s  t  m  t  >    <orogram  boay>  <  e  r>  a  s  t  a  t  e  > 
<progra<n  body>  :  :  =  <  s  t  a  t-  e^en  t  > 

!  <orogram  boay>  <statement> 
<statement>  ::=  <label>  <oarm  stmt>  <eos> 

<labe1>  <imnl  stmt>  <<=?os> 

<  1  a  b  e  1  >  <dimen  s t m t >  <eos> 
<1abel>  <common  5 1  m  f  >  <eos> 
<label>  <eguiv  st^t>  <eos> 

!  <label>  <tyoe  stmt>  <eos> 

!  <laoel>  <external  stmt>  <eos> 

<label>  <inf rinsic  st^t>  <eos> 

<label>  <save  stmt>  <eos> 

<1abel>  <data  stmt>  <eos> 

<  1  a  b  e  1  >  <stTitfunc  stmt>  <eos> 
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!  <label>  <entry  stmt>  <eos> 
1  <stmt  laoel>  <forTiat  stmt>  <eos> 
<end  state>  ::=  <  1  a  b  e  1  >  <  e  x  e  c  stmt  reserve a  *  o  r  d  > 

<label>  <i  dent  i  f  ier>  = 
<label>  <array  e)ement>  = 
<label>  <subst  rina  narr>e>  = 
<end  stn>t> 
<exec  stiit  reserved  «ord>  ::=  DO 

IF 

&SSIGM 

GO 

CONTINUE 

STOP 

PAUSE 

CALL 

P£A0 

W  KITE 

PRINT 

OPEN 

CLOSE 

inquire 

BACKSPACE 

ENOF  ILE 

REWIND 

RETURN 
<ena  stmt>  : : =  EwD 
<prog  stmt>  ::=  <label>  PROGRAM  <identifier>  <eos> 


ah 


<block  data  stmt>  ::=  <label>  BLOCK  DATA  <eos> 

!  <  1  a  D  e  I  >  BLOCK  DATA  <identifier>  <eos> 
<subr  stmt>  ::=  <label>  SUBROUTINE  <identi  f ier>  <eos> 

!  <1aoel>  SUBROUTINE  <arq  list>  <eos> 
<func  stmt>  ::=  <label>  <*unc  id> 

!  <  1  a  d  e  1  >  <number  t/pe>  <func  i  a  > 
!  <laDel>  <char  tyoe>  <func  ia> 
<func  ia>  ::=  FUNCTION  <ident i  f ier>  <eos> 

!  FUNCTION  <ioentiHer>  (  )  <eos> 
!  FUNCTION  <ara  li?t>  <ens> 

<  p  a  r  m  s  t  t,  t  >  ::=  PARAMETER  <ident  1  f  ier>  =  <constant> 

!  <  p  a  r  m  s  t  m  t  >  /  <ident  i  f ier>  =  <constant> 

<  i  m  p  1  stmt>  ::=  IMPLICIT  <  i  m p 1  1 i  s  t  > 

!   <  i  mp  1   s  t  t>  t  >  /   <lTp|   I  ist> 
<imDl  list>  ::-  <imol  list  Heaa>  <letter  range>  ) 

<  i  m  d  1  list  head>  ::=  <number  tyDe>  ( 

CHARACTER  ( 

CHARACTER  *  <inteaer  constant>  f 
<  i  m  d 1  list  heao>  <letter  range>  i 

<letter  range>  ::=  < i oen t i f i e r > 

!  <ident  i  f ier>  -  <ident  i  f  ier> 
<dimen  stmt>  ::=  DIMENSION  <array  dec  1 > 

!  <di.Ten  s  t  m  t  >  /  <array  aecl> 
<Common  stmt>  ::=  C  0  M  N1  U  N  <  c  o  m  m  o  n  naiie>  <coiTrnon  nlist  i  tem> 

!  <cnmrron  s  t  t>  t  >  /  <common  nlist  item> 
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<common  name>  '.  '  -    <emoty> 

!  <]  abel  common  name> 
!  <  d  o  u  b  1  e  s  I  a  s  h  > 

<  c  o  m  m  o  n  nlist  i  t  e  m  >  :  :  =  <iaent  i  f ier> 

!  <array  id> 
!  <a  r  ray  aec 1 > 

<  1  a  b  e  1  common  n  a  rn  e  >  11-    /  <identifier>  / 
<equiv  s  t  m t  >  :  :  =  EQUIVALENCE  <  e  a  u  i  v  n  1  i  s  t  > 

!  <  e  q  u  i  v  s  t  ^  t  >  f     <  e  a  u  i  v  n  1  i  s  t  > 
<eguiv  nl  i  st>  ::=  <  e  q  u  i  v  nlist  H  e  a  d  >  <  e  a  u \  v  nlist  i  t  e  m  >  ) 
<equiv  nlist  h  e  a  a  >  :  :  =  (  <  e  a  u  J  v  nlist  i  t  e  ^  >  t 

I  <  equ i  v  nlist  h  e  a  a  > 

<eau  iv  nlist  item>  , 
=  <ident  i  f i  er> 
<array  id> 
<array  element> 
<substrino  name> 
<type  stmt>  ::  =  <numcer  tyoe  stmt> 

!  <char  t  yoe  st  mt  > 
<number  tyoe  stmt>  '-'•-    <number  tyce>  <tvpe  item> 

J  <numoer  type  stmt>  t     <tvpe  item> 
<type  item>  ::=  <ioentifier> 

<a  r ray  i  d> 
<a  r  ray  dec  1 > 
<char  tvpe  stmt>  ::=  <char  tyne>  <cHar  name> 

i  <char  type  stmt>  t     <char  name> 


<  e  q  u  i  v  niist  item> 


<char  name>  ::=  <id?nti f ier> 

<i dent i f i er>  *  <char  len> 

<ar ra  y  aec 1 > 

<array  aec 1 >  *  <char  len> 
<a  r ra  y  i  d> 

<array  id>  *  <cnar  len> 
<extemal  s  t  m  t  >  ::=  EXTERNAL  <identifier> 

1  <e*tema1  s  t  m  t  >  t     <i  dent  i  f  ier> 
<  i  n  t  r  i  n  s  i  c  st"nt>  ::=  INTRINSIC  <ident  i  f  ier> 

i  <intrinsic  s  t  m  t  >  i     <ident  i  f  ier> 
<save  stmt>  ::=  S^vF 

i  <sove  1  i  s t  > 
<save  list>  ::=  SAVE  <  s  a  v  e  i  t  e  m  > 

<save  I i  s t >  t     < s a v e  i  t e m > 
<save  i  t  e  m  >  ::=  <iaenti f ier> 

<a  r ray  i  d> 
< I aoel  common  na^e> 
=  <data  Hst>  <data  clist  item>  / 
=  <  d  a  t  a  head>  <data  nlist  i  t  e  m  >  / 

<aata  list>  <data  clist  i  t  e  m  >  / 
=  DMA 
<data  heaa>  <data  nlist  item>  , 
<data  nlist  item>  ::-  <idpnt i  f ier> 

<array  id> 
<array  element> 
<Suost  ring  namp> 
<  i  mp 1 i  ea  do  1  i  s  t  > 


<data  stmt>  : 
<dat a  1  i  st >  : 

<data  head>  : 
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<data  clist  item>  ::=  <iaentifier> 

<cons t  ant  > 

<  i  n  t  e  g  e  r  constant>  *  <constant> 
<integer  constanf>  *  <identifier> 
<identifier>  *  <constant> 
<identifier>  *  <iaent 1 f ier> 
<imDlied  do  1  i  s  t  >  ::=  (  <array  element>  /  <do  Mst>  ) 

!  (     <  i  ii  d  H  e  d  ao  1  i  s  t  >  #.  <do  I  ist>  ) 
<strrtfunc  s  t  rn  t  >  :  :  =  <  a  r  a  1  i  s  t  >  =  <  e  x  n  > 

!  <icent  i  f ier>  (  )     -    <exn> 
<  e  n  t  r  y  S  t  m  t  >  ::=  ENTRY  <identifier> 
!  t H T  R  Y  <  a  r  a  list> 
i  ENTRV  <  i  aent i  f i e  r>  (  ) 
<format  stmt>  ::=  FORMAT  <  f  o  r  t  a  t  inout> 
<do  I ist>  ::-  <iaenti f ier>  -  <exp>  ,  <exp> 

!  <identifier>  =  <exo>  ,     <exn>  ,     <exp> 
<func  ref>  ::=  <identifier>  (  ) 

;  <arq  1 i st > 
<arq  list>  ::=  <arg  head>  ) 
<arg  heao>  ::=  <identifier>  (  <ara  elerrent> 

!  <arq  heaa>  ,     <arg  element> 
<arg  element>  ::=  <exc> 

!  <ar  ray  i d> 

:   * 

<array  dec  1 >  ::=  <array  id>  <dinen  decl  I i  st>  <dimen  dec! 
<dinen  dec)  1  i  s  t  >  ::=  (. 

!  <dimen  decl  1  ist>  <aimen  dec  1 >  / 
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<dimen  dec  1 >  ::  =  <exp> 

J  <exo>  :  <exD> 
<arrav  e  I  e  rn  e  n  t  >  ::=  <array  element-  1  ist>  <  e  x  p  >  ) 
<aray  element  list>  ::=  <arrav  ia>  ( 

!  <array  element  1 i s t >  <exc>  , 
<subst ring  name>  ::=  <ident  i  f ier>  (  <subst rinq  dec  1 > 

i  <array  element>  I  <substrino  dec  I > 
<sufcst ring  dec  1 >  :  :  =  <exp>  :  <exo>  ) 

!  <<=xd>  :  ) 
i  :  <exD>  ) 
i  :  ) 
<exr>  ::=  <  1  o  g  i  c  a  1  term > 

!  <exp>  ,UR.  <loaical  term> 
<loaical  term>  ::=  ^logical  factor> 

i  <locical  term>  .AND.  <  1  o  g  i  c  a  1  tactor> 
<logical  factor>  ::=  <logical  primary> 

!  .NOT.  <loaical  o  r  i  m  a  r  v  > 
<logical  orimary>  ::  =  <cnar  exp> 

!  <char  exp>  <rel  op>  <c^ar  exp> 
<char  exp>  ::=  <arith  exp> 

!  <char  exp>  <double  slash>  <ari  th  exp> 

V 

<arith  exo>  ::=  <an  th  term> 

+  <ari  th  term> 

-  <arith  term> 

<an  th  exp>  ¥    <arith  term> 

<ari  th  exp>  -  <ari  th  term> 
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<anth  term>  ::=  <arith  factors 

!  <arith  term>  /  <arith  facfor> 
1  <arith  term>  *  <an  tn  factor> 
<arith  fdCtor>  ::=  <arith  primary> 

J  <aritH  factor>  <expon  oo>  <ari  t h  primary> 
<  a  r  1  t  h  DriTiary>  :  :  =  <constant> 

<  1  den t  i  f i  er> 
<array  ele'1,ent> 
<substrinq  n a m e > 
<fijnc  ref  > 
<pa  ren  e  xo> 
<caren  exo>  ::=  t.  <axc>  j 
<constant>  :  :  =  <  i  n  t  e  g  e  r  constant> 
<real  const  an  t  > 
<dole  ore  constant> 
< 1 ooi  ca 1  const  an t  > 
<char  const  an t  > 
<complex  constant> 
<complex  constant>  ::=  C  <  r  e  a  1  constant>  f     <  r  e  a  1  constat t  >  ) 
<re I  op>  : : =  .LT . 
.LE. 
.EQ. 
•  NE. 
.GT. 
.GE. 

<loaical  constant>  ::  =  .I"UE. 

!  .FALoE. 
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<numoer  tvpe>  ::=  INTEGER 

RtAL 

DQUdLE  PRECISION 
CUMpLtX 
LOGICAL 
<char  type>  ::=  CHARACTER 

!  CnARACTLR  *  <char  len> 
<cnar  len>  ::=  <paren  exp> 

!  <inteqer  constant> 
!  (  *  ) 
<1 abe 1 >  : : =  <emot  v> 

;  <st  Tit  1  abe  1  > 
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APPENDIX  8  -  FORTRAN  GRAMMAR  StCTIUN  T/,0 


<program>  ::-  <orogram  body>  <end  stmt> 
<program  body>  ::  =  <statement> 

1  <proqraff'  body>  <statenent> 
<statement>  :  :  =  <  1  a  b  e  1  >  <  d  a  t  a  st,mt>  < e o s > 

<  1  a  b  e  I  >  < 1 o g i  f  s t m t > 
<laoe)>  <oo  <;  t  m  t  >  <eos> 

<  1  a  d  e  1  >  <entry  s  t  m  t  >  <eos> 

<  s  t  m  t  l a  b  e 1 >  <  f o  r m  a  t  s  t  m  t  >  <  e  o  s  > 

<  1  og  i  f  exec  s  t  r*  t  > 


<  1  o  g  i  f  exec  s  t  m  t  >  : 


=  <1abel>  <assign  s t m t >  <eos> 


<  I  aoe 

<  1  aoe 

<  1  aoe 

<  1  aoe 

<  1  abe 

<  I  aoe 

<  I  aoe 

<  1  abe 


>  <goto  s t m t >  <eos> 

>  <  a  p i  t  h  if  stmt>  <eos> 

>  <cont inue  s t m t >  <eos> 

>  <stoo  stmt>  <eos> 

>  <pausp  s  t-  m  t  >  <eos> 

>  <call  stmt>  <eos> 

>  <return  s  t  m  t  >  <eos> 

>  <read  write  orinr  str*t>  <eos> 


<end  st mt  >  : : 
<data  s  t  m  t  >  : 


<label>  <ooen  close  inqui  re  s  t  rr  t  >  <eos> 
<label>  <oacksoace  e  n  g  *  i  1  e  rewind  s  t  m  t  > 
<eos> 

END 

:  <datd  list>  <data  clist  item>  / 
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<data  head*  : 


<data  list*  ::=  <data  nead*  <data  nlist  item*  / 

<data  list*  <  d  a  t  a  clist  item*  / 
=  DATA 
<aata  h  e  a  a  >  <aata  nlist  i  t  e  m  >  t 
<data  nlist  item>  ::=  <iaentifier> 

<a  r ray  i  d> 
<  a  r  ra  y  el  emen  t  > 
<substring  n  a  rr,  e  > 
< i  m  p 1 i  e  d  go  list> 
:=  <identifier> 


<dat  a  c I  i  s  t  it  em*  : 


<Const;int> 


<integer  constant*  *  <ccnstant* 
<mte-jer  constant  *  <iaent  1  f  ier> 
<identifier>  *  <constant> 
<identifier>  *  <iaenti f i°r> 

<  i  m  p  1  i  e  d  do  list>  ::=  (  <array  element*  t     <do  list>  ) 

!  (  <  i  m  p  1  1  e  d  do  1  i  s  t  >  ,     <  a  o  list>  ) 
<pause  stmt*  ::=  PAUSE 

!  PAuSt  < integer  constant* 
!  PAUSE  <  c  n  a  r  constant* 
=  STOP 
STOP  <inteaer  constant* 
STOP  <cnar  constant* 
<continue  stmt*  ::=  CONTINUE 

<  r  e  t  u  r  n  stmt*  ::=  *  F  T  U  R  N 

!  RETURN  <exo> 
<anthif  stmt*  ::=  I  h  <paren  exo*  <aif  slaoels* 


<s t op  st mt  > 
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<  a  i  t  slabel s>  ::=  <inteoer  constant)  ,     <inteqer  constant 


<inteoer  constant> 
< 1 o  a  i  f  sfnt>  :  :  =  IF  <  c  a  r  e  n  exp>  <  1  o  a  1  f  exec  s  t  m  t  > 
<  a  s  s  i  q  n  s  t  m  t  >  ::=  ASSIGN  <integer  constant>  TO  <identifier> 

!  <identifier>  =  <exo> 
!  <array  el ement>  =  <exp> 
!  <sut)string  na7ie>  =  <exp> 
<do  stnt>  ::=  DO  <integer  constant>  <do  1  i  s  t  > 
<aoto  stmt>  ::=  GO  TO  <inteaer  constant> 

!  GO  10  <  s  t  m  t  label  Hst>  )  <  e  x  o  > 
!  GO  10  <  i dent  i  f  i  er> 

!  GO  TO  <identifier>  <  s  t  ^  c  I  s b  e 1  I  i s  t  >  J 
<stmt  laoel  list">  ::=  C  <  i  n  t  e  a  e  r  constant) 

!  <stmt  label  1ist>  t     <nteger  constant> 
=  C  ^LL  <  i  dent  i  f  i  er> 

CALL  <ara  !ist> 
:=  ENTRY  <identifier> 
!  ENTRY  <arq  1  i  st > 
!  ENTRY  <identifier>  (  ) 
<format  stmt>  ::=  FORMAT  <format  inout> 

<open  close  inquire  stmt>  ::=  <open  close  inquire  heaa> 

<e  xo>  ) 
!  <ooen  close  inquire  heaa> 
<  i  o  spec  >  ) 
<ooen  close  inquire  nead>  ::=  OPEN  ( 

!  CLOSF  ( 
!  INQUIRE  ( 


<ca  11  stmt  > 


<ent  ry  s  t  mt > 
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!  <open  close  inaui  re  heaa> 

<e  x  n>  t 
J  <oDen  close  inaui  re  heaa> 


<  i  o  soec  > 


<backspace  endtile  rewina  stmt>  : 


=  bACKSPACt  <ber  1 1 st> 
E n D K I L E  <ber  M  st> 
REWIND  <ber  1 i st> 
<her  I  i st  >  : : =  <exp> 

!  (  <exo>  ,  <  i  o  soec  >  ) 
!  (.  <io  scec>  t     <exD>  ) 
<  r  e  a  d  write  print  s  t  m  t  >  ::=  <  r  9  a  a  print  s  t  m  t  > 

!  <read  write  c  i  1  i  s  f  > 
!  <  r  e  a  d  writ0  i  o  I i  s  t  > 
<reaa  print  stmt>  ::=  K  E  A  D  <  e  x  p  > 

READ  <  a r r a v  i  d  > 
REAu  * 
PRINT  <exp> 
PRINT  <array  id> 
PRINT  * 

<read  print  s  t  m  t  >  r     <io  list  item> 
<reao  write  io  list>  ::=  <  read    write  ci  1  i  s  t  >  <io  list  itern> 

J  <  read  write  io  list>  > 
<  i  o  list  l t  em> 
<read  write  ci  list>  ::=  <read  write  H  e  a  d  >  <ci  list  i  t  e  ^  >  j 
<read  write  nead>  ::=  <read  paren> 

!  WRITE  ( 
!  <reari    write  h  e  a  a  >  <ci  list  i  t  e  n  >  / 
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<c i  list  i t  em>  :  :  = 


<e  xp> 

<  i o  SDec > 

<  a  P  r  a  v  i  d  > 


<arrav  block  item>  :  :  =  <array  elennent>  :  <array  elerT>ent> 

J  <arrav  element>  : 
{  :  <a  r  ray  el emen  t  > 
<  i  o  implied  do  1  l  s  t  >  ::=  <  c  o  rr  p  1  e  x  h  e  a  d  >  <do  list>  ) 

!  <io  do  list  nead>  <do  list>  ) 
<io  do  list  nead>  :  :  -  <  c  o  m  d  1  e  x  h e a d >  <  e  x  c  >  , 

(  <a  r  ra v  i  d>  , 
(     < array  o  1  o  c  *  i  t  e  m  >  , 
C  <io  irnolied  no  list>  > 
<io  do  list  head>  <io  list  iterr>  , 
<io  list  i  t  e  m  >  ::=  <  e  x  o  > 

<arrav  ia> 
<array  block  item> 
<  i  o  i  mpl i  ed  do  1 ist> 
:=  UNIT  =  <exp> 

ERR  =  <mteger  constant> 

REC  =  <exp> 

END  =  <integer  constant> 

F  M  T  =  <array  id> 

F;MT  =  <exp> 

FMT  =  * 

FILE  =  <exo> 

S  I  A  f  U S  =  <exo> 


<i  o  snec>  : 
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BLANK  =  <exp> 

ACCESS  =  <exo> 

FQRM  =  <  e  x  p  > 

RECL  =  <exo> 

V!  A  X  R  E  C  =  <exo> 

EXIST  =  <exp> 

OPENED  =  <exo> 

NU^bER  =  <exc> 

NAMED  =  <  e  x  p  > 

NAME  =  <  e  x  c  > 

N E  X  T  R  E  C  =  <exc> 
<do  I i  st>  :  :  -    <ioentifier>  =  <e*o>  f     <exc> 

< 1  den t i  f i e r >  =  <exp>  f     <exc>  ,  <exo> 
<func  ret>  ::=  <Hent  i  f  i  er>  (  J 

i  <aro  1  i s  t > 
<  a  r  q  1  i  s  t  >  :  :  =  < a r g  n  e  a  d  >  ) 

<arq  head>  ::=  <  i  den  t  i  f  i  e  r>  (  <ara  elemeno 
!  <ara  head>  t     <arg  element> 


<a  rq  el emen  t  >  : 


=   < A  XC> 

<array  i  d> 

*  <inteqer  constant> 


<arrav  element >  ::=  <array  element  1  i  s  t  >  <exp>  ) 
<aray  element  I  i  s  t  >  ::=  <  a  r  r  a  y  io>  ( 

!  <array  element  1  i  s  t  >  <exn>  , 
<substrinq  name>  '-  '.-    <identi  f  ier>  (  <substrinq  dec  1  > 

!  <arrav  element>  (  <suDstrinq  decl> 
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<substrino  dec  1 >  ::=  <exo>  :  <exp>  ) 

I  <exn>  :  ) 

i  :  <exo>  ) 
!  :  ) 
<exp>  : : =  <loaicdl  term> 

!  <  e  x  p  >  .OR.  <loaica1  t  e  r  71  > 
<loaical  term>  ::=  <loqical  factor> 

!  <locica1  term>  .AND.  <lcgical  f  a  c  t  o  r  > 
<logical  factor>  ::=  <logical  prii,ary> 

J  .NOT.  <loaical  Dri-narv> 
<!oqiC3l  d  r  i  71  a  r  v  >  ::=  <cnar  exp> 

!  <  c  h  a  r  e  x  o  >  <rel  op>  <  c  h a  r  exo> 

<  c  n  a  r  exo>  :  :  =  <  a  r  i  t  h  exp> 

J  <cnar  exp>  <doubie  s!  ash>  <aritn  exp> 

<  a  r  i  t  h  exp>  ::=  <  a  r i  t  h  term> 

+  <ari  th  t  e  rnn> 
-  <ari  th  t<=rrn> 
<aritn  exp>  t  <arifn  term> 
<an  th  exp>  -  <ari  th  terrr> 

<ari th  term>  ::=  <ari th  factor> 

J  <ari  th  term>  /  <an  tn  tactor> 
!  <arith  term>  *  <arith  factor> 
<arith  factor>  ::=  <ari  tn  primary> 

I  <ari  th  factor>  <expon  cd>  <  a  ri  t  h  p  r  i  rr  a  r  y  > 
<an  th  primary>  ::=  <constant> 

!  <icent  i  f  ier> 
!  <array  ele^ent> 
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<substrinq  name> 
<f unc  ref> 
<pa  ren  exp> 
<oaren  exp>  ::=  (  <exr>  ) 
<constant>  ::  =  <inteqer  constant> 
<reai  const  an t> 
<dble  pre  constant> 
<1 oqical  constant> 
<char  const  an  t  > 
<corT,plex  constant 
<complex  constant>  ::-  <como]ex  head>  <exo>  J 
<ccTiplex  heao>  '.  '.  -     (  <exo>  , 
< re l  op>  : : =  . LT . 
.LE. 
.EQ. 
.NE. 
.GT. 
.GE. 

<logical  constant>  ::=  .TRUE. 

i  .FALbE. 
<1 abel >  :  : =  <empt  y> 

!  <  s  t  m  t  label> 
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APPfcNDIX  C  -  FORTRAN  GRAMMAR  FOR  STATEMENT  ORDtR 


<prograip>  ::=  <orogran*  uni  t> 
!  <sut>progra^> 

!  <suborogram>  <Drogram  unit> 
<Drograti  uni  t  >  il-    <main  orogram> 

!  <crcgram  uni  t>  <suborogram  uni  t> 
<subDrograrn>  ::=  <subcrogran  uni  t> 

i  <suboroqram>  <suDorogram  u  n  i  t  > 
<subprocn3Ti  u  n  i  t  >  I  :  -     <function  5UDnrogra^> 

!  <suo routine  suhproaram> 
!  <  o  1  o  c  *  uata  subproqram> 
<main  orogram>  ::=  <prog  stnnt>  <main  Drognam  booy> 

J  <main  program  boav> 
<subrout  me  subprograrr>  ::=  <surr  s  t  v  t  >  <sub  program  body> 

<subr  s  t  m  t  >  <  m  a  i  n  program  bocv> 
<suor  s  t  m  t  >  <  o  1  o  c  <  data  b  o  d  y  > 
<subr  stmt>  <end  stmt> 
<function  suborogram>  ::=  <func  Stmt>  <sub  program  body> 

<func  stmt>  <main  orograrr  body> 
<func  s t m t >  <oloc<  data  body> 
<func  s  t  m  t  >  <end  stmt> 
<block  data  suborograrr>  ::=  <block  data  strrt> 

<b 1 oc  k  data  Doay > 
!  <Dloc<  data  s  t  rr  t  >  <ena  stmt> 


<main  program  DOdy>  ::=  <main4  exec>  <end  stmt> 
<subproqram  boay>  ::=  <  m  a  i  n  1  i  m  o  I  >  <ena  s  t  m  t  > 

<  m  a  1  n  ^  SDec>  <end  s  t  rr.  t  > 
<maini  func>  <end  stmt> 
<subl  i  m  o  1  >  <  e  n  d  s  t  m  t  > 
<sud2  spec>  < e n d  s t m t > 
<sub3  *unc>  <eno  stnt> 
<sub'J  exec>  <  e  n  d  strr, t> 


<block  data  boav>  : 


<b  I  okc!  spec> 


<3uoS  return>  <end  s t m f > 
=  <h)okl  i-nol>  <end  stmt> 
<blokd  soec>  <end  ?trr>t> 
<  o  1  o  k  3  d  a  t  a  >  <end  s  t  ™ t > 
<hl  okI  •  i  itidI  >  ::=  <  i  m  p  1  s  t  rn  t  > 

<  d  a  r  m  s  t  m  t  > 
<blo<l  i  nn  o  1  >  <  i  m  p  1  s  t  m  t  > 

<  b  1  o  k  1  i  m  p  I  >  <  p  a  r  m  s  t  m  t  > 
=  <spec  stmt> 

<blokl  imDl>  <soec  stmt> 
<blo<?  spec>  <soec  stmt> 
<blo*2  spec>  <parm  stmt> 
:=  <dat  a  stmt> 

<blo<l  i  m  p  1  >  <data  s  t  m  t  > 
<blok<?  spec>  <data  stmt> 
<b)o<3  data>  <data  stmt> 
=  <  f  o  rn- a  t  stpnt> 
<blokl   i  mo  I  >  <format  S  t  n-i  t  > 

<  -m  a  i  n  1  i  m  p  1  >  <  i  m  p  1  s  t  m  t  > 


<b 1 oki  dat a> 


<ma  i  n 1  i  mp ] > 
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<ma  i  n<f  spec  > 


<ma i n  3  f  unc > 


<main/J  exec> 


<rnainl  i  itid  1  >  <oarm  stmt> 

<main1  imol>  <format  stmt> 

:  <o t  he  r  soec  s  t  m t  > 

<blokl  imDl>  <other  soec  s t m c > 

<  b  1  o  <  2  spec>  <otner  soec  s t m t > 
<blo*2  spec>  <forrnaf  stmt> 
<mainl  i  mo  I  >  <other  soec  stiit> 
<nainl  imol >  <soec  Stmt> 
<main2  soec>  <  o  t  h  e  r  spec  s  t  "n  t  > 

<  m  a  i  n  2  spec>  <  s  p  e  c  s  t  m t  > 

<  m  a  i  n  2  soec>  <  p  a  r  m  s  t  m  t  > 
<main(?  spec>  <format  stmt> 

<stmtfunc  S  t  m t  > 

<  b  1  o  <  1  i  m  p 1 >  <stmt tunc  s  t  m t  > 
<blo<2  sppc>  <stiit  tunc  st^t> 
<0lo<3  dat-a>  <sf"ntfunc  st^t> 
< b 1 o k 3  data>  <  f  o  r  m  a  t  s t m t > 
<rrainl  i  mo  1  >  <stntfunc  Stmt> 
<mai  nl  imcl >  <data  5tmt> 
<main2  spec>  <stmtfunc  Stmt> 

<  m  a  i  n  2  SDec>  <aata  s  t  m  t  > 

<  m  a  i  n  3  func>  <st"ntfunc  S  t  m  t  > 
<main3  func>  <aata  stnt> 
<Tiain3  func>  <forn-*at  s  t  m  t  > 

<exec  s  t  m  t  > 

<bl0Kl  imol>  <exec  Stmt> 

<b)o<2  5pec>  <exec  stmt> 
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<sub 1  i  mp 1 > 


<sub<?  scec> 


<blok3  riata>    <exec  stmt> 
<mainl  i  mp  1  >  <exec  stmt> 

<  m  a  i  n  2  s  p  e  c  >  <evec  S  t  m  t  > 

<  m  a  i  n  3  func>  <  e  x  e  c  s  t  m  t  > 
<main1  exec>    <exec  s  t  m  t  > 
<main4  exec>  <data  stmt> 
<mainil  exec>  <format  stmt> 
<entry  strnt> 

<p1o^l  impl>  <entry  stmt> 
<mainl  i<rpl  >  <enf  rv  s  t  m  t  > 
<Subl  i  mp  1  >  <impl  stmt> 

<  s  u  o  1  i  m d 1 >  <p  a  r  m  s  t  m  t  > 
<suDl  i  mo  1  >  <forTiat  s  t  ^  t  > 
<3uDl  imrl>  <entry  s t m t > 

<save  stTif> 

<  b  1  o  k  1  imp1>  <save  s  t  m  t  > 
<Dlok<f  spec>  <save  stmt> 
<blok<2  soec>  <enf rv  sfnt> 
<mainl  impl>  <save  stmt> 
<main<;  s  d  e  c  >  <save  stmt> 

<  m  a  l  n  <£  soec>  <entrv  stmt> 
<suol  impl>  <other  soec     stmt> 
<subl  impl>  <SDec  stmt> 
<sud?  spec>  <  s  a  v  e  s  t  m  t  > 
<suo<?  spec>  <other  spec  s  t  m  t  > 
<sud2  spec>  <soec  stmt> 
<subi?  spec>  <  p  a  r  m  s  t  m  t  > 
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<  s  u  b  4  e  x  e  c  > 


!  <sub?  sppc>  <format  stmt> 
!  <sub<?  spf»c>  <entry  stmt> 
<sub3  func>  ::=  <subl  itid1>  <stmtfunc  stmt> 

<  s  u  b  1  i  m  d  1  >  <  d  a  t  a  s  t  m  t  > 

<  s  u  b  2  spec>  <stmt  func  s  t  m  t  > 
<sud2  spec>  <data  stmt> 
<b1ok3  data>  <entry  st<nt> 

<  n  a  i  n  3  func>  <  e  n  t  r  y  s  t  ^  t  > 
<suo3  func>  <s'' tit  func  Stmt> 

<  S  u  o  3  'unc>  <  d  a  t  a  strnt> 

<  s  u  b  3  func>  <format  s  t  m  t  > 
<Sun3  f urc>  <ent  f y  s t t t > 

::=  <suhl  imcl >  <  p  x  e  c  s  t  m  t  > 

<  s  u  c  2  s  d  e  c  >  <exec  s  t  m  t  > 
<suo3  func>  <exec  stTit> 
<main4  exec>  <enf  rv  stmt> 
<3ud'4  exec>  <  e  x  e  c  st",t> 
<subU  exec>  <aata  stmt> 
<sub4  exec>  <for^at  s  t  "n  c  > 
<suo4  exec>  <entry  stmt> 

<subb  return>  ::=  <return  s  t  nn  t  > 

<  b  1  o  k  1  i  m  p  1  >  <return  s  t  m  t  > 
<blo*2  spec>  <return  stmt> 
<blo^3  data>  <return  stmt> 
<mainl  inpl  >  <  r  e  t  u  r  n  s  t  m  t  > 
<main2  soec>  <return  stmt> 
<main3  func>  <return  s t m t > 
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<SDec  s  t  m  t  >  : 


<main4  exec>  <re^urn  sf mt> 

<suDl  i  m  d  1  >  <return  stmt> 

<sudP  spec>  <return  stmt> 

<sub3  func>  <return  s  t  m  t  > 

<  s  u  D  4  exec>  <return  s  t  m  t  > 
<suo5  return>  <return  stmt> 
<sud5  return>  <e»ec  Stmt> 

<  s  u  o  5  r e t u r n >  <  a  a  t  a  s t m t > 
<suu5  return>  <  f  o  r  m  a  t  s  t  m  t  > 

<  s  u  c  S  r  e  t  u  r  n  >  <entry  s  t  m  t  > 

=   <(iirpen  S  t  m  t  > 

<COinT-on  s  tmt  > 


<eou  i v  s  t m t  > 

<tvpe  s t mt  > 
<  o  t  h  e  r  spec  s  f  rr.  f  >  ::=  <external  s  t  m  t  > 

!  <int  rinsk  3  t  m  t  > 
<exec  stmt.  >  ::=  <assiqn  s  t  oi  t  > 

<go t  o  s  t  mt  > 

<anthif     stmt  > 

< 1 ogi  f     stmt> 

<dO     S  trr  t  > 

<Con t  i  nue    sfnt> 

<stoo  stmt> 

<pause  s  t  mt  > 

<  read  stmt> 

<write  stmt> 

<print  s tmt  > 


hi 


<  rew  inn  s  t  mt > 

<backscace  s  t  mt  > 
<endf  i  1 e  s t  mt  > 
<ooen  s  t mt  > 
<c'ose  s  t  m  t  > 

<  i  nqu ire  Stmt> 
<ca 1  1  s  t  m t  > 


hP, 
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